Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-135.txt

Text File | 1994-12-08 | 41.0 KB | 1,061 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 07 Jul 92       Volume 1 : Issue 135

Today's Topics:

    C++ Critique in comp.lang.c++
    Drawing on the MeNuBaR!
    Latest Inside Mac Printings?



-------------------------------------------------------

From: [e-mail] (Ian Joyner)
Subject: C++ Critique in comp.lang.c++
Date: 8 Apr 92 12:17:26 GMT
Organization: ACUS Australian Centre for Unisys Software, Sydney

Have Apple made a mistake by adopting the C++ route. I have posted a critique
in comp.lang.c++ which may help answer such questions.
- --
Ian Joyner                                     ACSNet: [e-mail]
ACUS (Australian Centre for Unisys Software)   Internet: [e-mail]
Tel [phone]      Fax [phone]       UUCP: ...uunet!munnari!syacus.oz

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 11 Apr 92 23:47:30 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Ian
Joyner) writes:
>
> Have Apple made a mistake by adopting the C++ route. I have posted a critique
> in comp.lang.c++ which may help answer such questions.

You might as well ask why the whole PC computing industry has made a
mistake by adopting C++. We are not alone in the same boat...

Cheers,
Kent Sandvik, Dynamic Language Evangelist (all those Algol-based languages
are the same anyway).

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Tue, 14 Apr 1992 01:08:18 GMT

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
>
> In article <[e-mail]>, [e-mail] (Ian
> Joyner) writes:
> >
> > Have Apple made a mistake by adopting the C++ route. I have posted a critique
> > in comp.lang.c++ which may help answer such questions.
>
> You might as well ask why the whole PC computing industry has made a
> mistake by adopting C++. We are not alone in the same boat...
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Great, we're not the only people on the Titanic!  Reminds me of the old
Tom Lehrer song "We'll All Go Together When We Go".

> Cheers,
> Kent Sandvik, Dynamic Language Evangelist
>(all those Algol-based languages are the same anyway).

"True but probably irrelevant."

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Looking for a good book on Eiffel.


+++++++++++++++++++++++++++

From: [e-mail] (Ian Joyner)
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Sat, 18 Apr 1992 13:09:53 GMT

[e-mail] (Kent Sandvik) writes:

>In article <[e-mail]>, [e-mail] (Ian
>Joyner) writes:
>>
>> Have Apple made a mistake by adopting the C++ route. I have posted a critique
>> in comp.lang.c++ which may help answer such questions.

>You might as well ask why the whole PC computing industry has made a
>mistake by adopting C++. We are not alone in the same boat...

Kent,

Maybe it's because we don't expect any better of the PC industry, but
expect Apple to do something better.
- --
Ian Joyner                                     ACSNet: [e-mail]
ACUS (Australian Centre for Unisys Software)   Internet: [e-mail]
115-117 Wicks Rd, North Ryde, N.S.W, Australia 2113.
Tel [phone]      Fax [phone]       UUCP: ...uunet!munnari!syacus.oz

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 21 Apr 92 19:01:48 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Ian Joyner) writes:
> >You might as well ask why the whole PC computing industry has made a
> >mistake by adopting C++. We are not alone in the same boat...

> Maybe it's because we don't expect any better of the PC industry, but
> expect Apple to do something better.

These are my personal opinions, either we could go out there and launch
a new language, or then our developers are screaming about problems with
cross-platform work and we need to implement/use a language which works on most
platforms. This is more of a political issue, than  'may the best language
rule'.

Sorry, the commercial computing world is ruled by $$$, not academical
and computer science issues. Otherwise most if not all Algol style languages
should be dead by now, and we would use object oriented dynamic languages.

Personally I don't care what language a developer uses, as long as the
application/hack is cool and end users love it. But true, a really
revolutionary language would certainly spawn off more intriguing applications,
in a quicker time frame. I don't see any such languages in the near horizon,
for instance Eiffel and Modula-3 are still same old Algol compiler/linker
static typing languages which certainly are not suitable for component SW.

Anyway, this starts to be something not related to c.s.m.p, so either
we could take this offline, or move the discussion to comp.programming.

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Thad Humphries)
Date: Wed, 22 Apr 1992 19:47:51 -0500

  KS> Sorry, the commercial computing world is ruled by $$$, not academical
  KS> and computer science issues. Otherwise most if not all Algol style
  KS> languages
  KS> should be dead by now, and we would use object oriented dynamic
  KS> languages.

My geneology might be off but isn't Algol->Pascal->Ada one language family
branch? I know the CS and SE departments at George Mason would disagree if you
count Ada as an Algol style language.  They aren't keen on my proposal to write
my MS thesis in THINK C but it sure beats the pants off Meridian Ada.


+++++++++++++++++++++++++++

From: [e-mail] (Ray Johnson)
Organization: Georgia Institute of Technology
Date: Thu, 23 Apr 1992 14:40:10 GMT

In article <[e-mail]> [e-mail] (Thad Humphries) writes:
>
>  KS> Sorry, the commercial computing world is ruled by $$$, not academical
>  KS> and computer science issues. Otherwise most if not all Algol style
>  KS> languages
>  KS> should be dead by now, and we would use object oriented dynamic
>  KS> languages.
>

Who said this?  I agree that the commercial world is ruled by money.
However, it is the large investment in existing software that has
kept languages like Fortran and Cobal alive all these years.  Sure,
much of the commerical world would like to use OO dynamic languages
but the economical costs of changing all libraries etc. is just too
high.



- ------------------------------------------------------------------------------
Raymond W. Johnson
Graphics, Visualization, and Usability Center
College of Computing
Georgia Institute of Technology
801 Atlantic Drive                                       [phone] (Work)
Atlanta, GA 30332-0280                                   [phone] (Home)

+++++++++++++++++++++++++++

From: [e-mail] (Lance 'Moof' Kimes)
Date: 23 Apr 1992 16:30:05 -0700
Organization: University of Southern California, Los Angeles, CA


In article <[e-mail]>, [e-mail] (Ray Johnson) writes:
|> In article <[e-mail]> [e-mail] (Thad Humphries) writes:
|> >
|> >  KS> Sorry, the commercial computing world is ruled by $$$, not academical
|> >  KS> and computer science issues. Otherwise most if not all Algol style
|> >  KS> languages
|> >  KS> should be dead by now, and we would use object oriented dynamic
|> >  KS> languages.
|> >
|>
|> Who said this?  I agree that the commercial world is ruled by money.
|> However, it is the large investment in existing software that has
|> kept languages like Fortran and Cobal alive all these years.  Sure,
|> much of the commerical world would like to use OO dynamic languages
|> but the economical costs of changing all libraries etc. is just too
|> high.
|>

I think you miss understand his posting, because you both are saying essentially the
same thing(ie. that coporations are not willing to give up using older languages
because they have invested a lot of money in them.)

Lets take the time to read these article, instead of seeing one word we don't like
and starting a flame war, especially when both parties already agree.

Lance Kimes
USC

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 26 Apr 92 00:49:25 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Ray
Johnson) writes:

> In article <[e-mail]>
[e-mail] (Thad Humphries) writes:

> >  KS> Sorry, the commercial computing world is ruled by $$$, not academical
> >  KS> and computer science issues. Otherwise most if not all Algol style
> >  KS> languages
> >  KS> should be dead by now, and we would use object oriented dynamic
> >  KS> languages.

> Who said this?  I agree that the commercial world is ruled by money.
> However, it is the large investment in existing software that has
> kept languages like Fortran and Cobal alive all these years.  Sure,
> much of the commerical world would like to use OO dynamic languages
> but the economical costs of changing all libraries etc. is just too
> high.

OK, I need to clarify my point. I've seen N times the same argument
that language X stinks, and that language Y has features such as
XYZ which beats X's feature set any time.

That's great. However, we have to look at the practical point of
the commercial software industry. A project manager would have
a heart attack if the programmers demanded a new language every year.

One reason C++ took off was that many companies switched over to C
use, especially in the PC world, and it's a very smooth transition to
get over to the OOP world by converting over to C++ from C. I don't
actually mind about this matter, C++ is certainly better than C in
many cases (data abstraction, inheritance, framework design).

However, if we are looking at cost reductions concerning *huge* applications,
C++ will never provide us with those figures. There's a need for
a new paradigm in computing, something OOP:ish, something dynamic,
and something easy to learn. Also, if we want to take the next
step where we want to create constraints based applications, and
intelligent agents, we need better tools for this. Finally
if we want to move to the golden era of software component, we
certainly needs more dynamic handling in the language.

Eiffel is a nice language, but it does not solve the problems in the long
term, we need to achieve a 10 or 100 times bigger change, instead of just
switching from one Algol-style language to a better one.

End of my preaching :-).

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Ian Joyner)
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Wed, 29 Apr 1992 03:21:38 GMT

(If anyone hasn't seen the referenced critique yet, you may obtain it from
[e-mail], or reply to this posting)

[e-mail] (Kent Sandvik) writes:

>> >  KS> Sorry, the commercial computing world is ruled by $$$, not academical
>> >  KS> and computer science issues. Otherwise most if not all Algol style
>> >  KS> languages
>> >  KS> should be dead by now, and we would use object oriented dynamic
>> >  KS> languages.

Precisely, that is why we should stop mucking around with C and C++
style languages, which end up costing us immeasurable heaps. If we
are going to realise the benefits of OO then it should be done properly,
and get away from the 25 year old error prone practices of C. This is
not an academic, or computer science issue, the base line is how to
produce software that works in a timely and economic fasion.

>OK, I need to clarify my point. I've seen N times the same argument
>that language X stinks, and that language Y has features such as
>XYZ which beats X's feature set any time.

You are talking about religious/academic arguments. That is why in
the critique, I tried to make it practical, and to illustrate how
language features DO affect day to day practice.

>That's great. However, we have to look at the practical point of
>the commercial software industry. A project manager would have
>a heart attack if the programmers demanded a new language every year.

>One reason C++ took off was that many companies switched over to C
>use, especially in the PC world, and it's a very smooth transition to
>get over to the OOP world by converting over to C++ from C.

But what you show here is that things do change over time. Perhaps
the FORTRAN bases lost out to C over ten years. But now C is old
creaking at the knees and has too many problems to be redeemable,
even by adding support for OO. As computer professionals, we should
monitor improvements, and decide when is an appropriate time to change,
and not just go with a fad. We are at a time now, when to get away from
the C++ mess, it would be a good time to examine, and plan how to
bring about changes in the next 2 to 10 years.

It's also a very debatable point as to whether C to C++ is a smooth
transition. In our experience this is not so. Most people just compile
their C with a C++ compiler, and hey presto, suddenly they are claiming
to be doing object-oriented programming. C++'s implementation of OO
is much to obscure for such a smooth transition, and that's on top
of having to adjust mental processes to the OO paradigm.

>Eiffel is a nice language, but it does not solve the problems in the long
>term, we need to achieve a 10 or 100 times bigger change, instead of just
>switching from one Algol-style language to a better one.

If you are going to wait for something that makes 10 to 100 times
improvements, you are going to be waiting forever.  Eiffel is
significantly better that C++ in many respects.  It actually has
sharable and reusable libraries that you can talk about.  Adopting such
a language as Eiffel will definately be a step (or leap) in the right
direction, but don't expect the hard problems of programming to suddenly
become simple, just a bit more understandable.

I also don't know what you mean by Algol-style languages. Are you talking
about syntax style, semantic concepts, block structured, or what? I
think many languages adopt elements of Algol, and may be thus classified
as algol-style. The algol heritage is quite a rich one, and you will not
be able to write off a language because it's 'algol-style'.

And you thought Kent could preach :-)
- --
Ian Joyner                                     ACSNet: [e-mail]
ACUS (Australian Centre for Unisys Software)   Internet: [e-mail]
115-117 Wicks Rd, North Ryde, N.S.W, Australia 2113.
Tel [phone]      Fax [phone]       UUCP: ...uunet!munnari!syacus.oz

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 12 May 92 04:09:16 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Ian Joyner) writes:
> [e-mail] (Kent Sandvik) writes:
> >Eiffel is a nice language, but it does not solve the problems in the long
> >term, we need to achieve a 10 or 100 times bigger change, instead of just
> >switching from one Algol-style language to a better one.
>
> If you are going to wait for something that makes 10 to 100 times
> improvements, you are going to be waiting forever.  Eiffel is
> significantly better that C++ in many respects.  It actually has
> sharable and reusable libraries that you can talk about.  Adopting such
> a language as Eiffel will definately be a step (or leap) in the right
> direction, but don't expect the hard problems of programming to suddenly
> become simple, just a bit more understandable.

Yes, I'm speaking for a language/environment which is 10..100 times better
than C/C++ and Eiffel. Bill Joy, another proponent of really-high level
languages once stated, that if an improvement in the computing field is
twice, or less than ten times better than an old one, it's not worth
pursuing. I agree, it's time to leave the statically typed languages
into the realms of embedded systems and time-critical real-time environments.

Application development should be as painless as jamming in a studio. That's
the way we will create the super-applications of the future - not by
switching from a lesser object oriented static language to the slightly
better static one.

Eiffel is still suffering from the lack of decent runtime binding
dynamics (we are not talking about shareable libraries, we are
talking about dynamically changed libraries), or functions as first class
members, or a meta-object protocol, or small/simple building block systems,
or component based document programming, or... (I could go on...)

> I also don't know what you mean by Algol-style languages. Are you talking
> about syntax style, semantic concepts, block structured, or what? I
> think many languages adopt elements of Algol, and may be thus classified
> as algol-style. The algol heritage is quite a rich one, and you will not
> be able to write off a language because it's 'algol-style'.

The inheritance tree of Algol spawns widely across the range of computer
languages, all the way to C, C++, Pascal and Eiffel. I'm talking about
another strand of software languages based on either LISP or Smalltalk
derivates. Even better, take the two nice things from LISP and Smalltalk,
dynamic binding and object messages, and you start to have a real
killer language. And as for parenthesis, that's a syntax issue, and we
should really look into semantic issues.

> And you thought Kent could preach :-)

Sorry, I'm an agnostic :-).

Cheers,
Kent
Dynamic Languages is the future, leave static languages to AT&T, Ericsson
and General Electrics.

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dakin)
Organization: Oceania Health Care Systems
Date: Thu, 14 May 92 19:40:14 GMT

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:

> Even better, take the two nice things from LISP and Smalltalk,
> dynamic binding and object messages, and you start to have a real
> killer language.

It sounds like you are talking about Objective-C...

> And as for parenthesis, that's a syntax issue, and we
> should really look into semantic issues.

How do you feel about brackets? ([...])

- --
    Steve Dakin                        Oceania Health Care Systems
 [e-mail] (NeXT mail)         Palo Alto, CA [phone]
 [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Amanda Walker)
Organization: Visix Software Inc., Reston, VA
Date: Fri, 15 May 92 22:33:08 GMT

[e-mail] (Kent Sandvik) writes:
> Even better, take the two nice things from LISP and Smalltalk,
> dynamic binding and object messages, and you start to have a real
> killer language.

Ever looked at Self?  It's waaaaaaaay cool.  And it would be a natural on
the Macintosh...  Sort of a "RISC SmallTalk" with a killer incremental
compiler.


Amanda Walker                        [e-mail]
Visix Software Inc.                     [phone]
- --
"It was supposed to be a devastatingly withering and dismissive
 remark.  I'll just have to try harder next time."
        -- Steve Dyer

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 16 May 92 23:19:51 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Steve Dakin)
writes:
>
> In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>
> > Even better, take the two nice things from LISP and Smalltalk,
> > dynamic binding and object messages, and you start to have a real
> > killer language.
>
> It sounds like you are talking about Objective-C...

Actually, I got my Objective-C package from the Apple Library a
day ago, and most likely I will write a review about this MPW package
to any of the magazines that dares to publish my stuff :-).

I personally think that Objective-C really belongs to the static/
Algol language thread, even if their notion of dynamic binding
as part of the language is certainly nice. Compare with with C++
where more of this binding has to be emulated just now with ugly
runtime library support due to no standard today (yes, it will
happen...). To some degree flexible dynamic library modules also
emulate this, actually.

However the notion of dynamic object oriented languages also has
other side-features, such as functions as first-class members,
and especially typeless coding, something which is the total
opposite of a C/Objective-C environment.

> > And as for parenthesis, that's a syntax issue, and we
> > should really look into semantic issues.

> How do you feel about brackets? ([...])

How do you feel about curly brackets {}? Especially on a Swedish
ASCII-7 keyboard...

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 17 May 92 22:39:00 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Amanda Walker)
writes:
> [e-mail] (Kent Sandvik) writes:
> > Even better, take the two nice things from LISP and Smalltalk,
> > dynamic binding and object messages, and you start to have a real
> > killer language.

> Ever looked at Self?  It's waaaaaaaay cool.  And it would be a natural on
> the Macintosh...  Sort of a "RISC SmallTalk" with a killer incremental
> compiler.

Yes, I have. Anyone doing a commercial version of Self? Just now it seems
to be the academical sandbox where all the former Smalltalk people have
gathered around. But I'm still waiting for any more commercial
implementations...

A lot of of the nice things with Self has to do with various lazy- optimizations
(lazy compiling, lazy evaluation, lazy documentation writing, sorry wrong
statement...).

Anyway, if we are talking about 'RISC-ish' languages, then Scheme is a LISP
RISC language! The future looks bright, all we need now is more commercial
interest in the future of application languages. I guess a couple more years
of C++ will do it, and then the programmer rebel movement should begin :-).

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Ian Joyner)
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Wed, 20 May 1992 02:17:25 GMT

[e-mail] (Kent Sandvik) writes:

>Anyway, if we are talking about 'RISC-ish' languages, then Scheme is a LISP
>RISC language! The future looks bright, all we need now is more commercial
>interest in the future of application languages. I guess a couple more years
>of C++ will do it, and then the programmer rebel movement should begin :-).

Kent,

What do you mean 'then'? I have had enough of untidy languages like C++. The
programmer rebel movement has already begun.
- --
Ian Joyner                                     ACSNet: [e-mail]
ACUS (Australian Centre for Unisys Software)   Internet: [e-mail]
115-117 Wicks Rd, North Ryde, N.S.W, Australia 2113.
Tel [phone]      Fax [phone]       UUCP: ...uunet!munnari!syacus.oz

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 20 May 92 19:43:44 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Ian Joyner) writes:
> [e-mail] (Kent Sandvik) writes:
>
> >Anyway, if we are talking about 'RISC-ish' languages, then Scheme is a LISP
> >RISC language! The future looks bright, all we need now is more commercial
> >interest in the future of application languages. I guess a couple more years
> >of C++ will do it, and then the programmer rebel movement should begin :-).

> What do you mean 'then'? I have had enough of untidy languages like C++. The
> programmer rebel movement has already begun.

Yes, but it needs to gain momentum, and as long as we have all these
magazine blurbs writing glorifying articles about C++ use it will take
some time before programmers realize that they have been tricked :-).

Once again, once the rebellion starts, let's select a language paradigm
which is 100 times better than the current one, a major step is better
than many, many minor ones. OODLs before OOSLs (OOSL - object oriented
static language, OODL - object oriented dynamic language).

Yet again, these are my private comments, and yes I'm a C++ support
engineer.

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Date: 22 May 92 15:20:02 GMT
Organization: Instructional Technology Laboratory, University of Michigan

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
...
>
>Yes, but it needs to gain momentum, and as long as we have all these
>magazine blurbs writing glorifying articles about C++ use it will take
>some time before programmers realize that they have been tricked :-).
>
>Once again, once the rebellion starts, let's select a language paradigm
>which is 100 times better than the current one, a major step is better
>than many, many minor ones. OODLs before OOSLs (OOSL - object oriented
>static language, OODL - object oriented dynamic language).
>

I'd love to try one out... right now I'm using C++ on the PC platform
and THINK C on the Mac. Suppose you are a programmer like me that is
interested in getting in on the OODL wave early. What languages
would be appropriate to look at?  I've heard Scheme, Lisp, and
Smalltalk mentioned. Any others? (And are any of them available as
shareware or PD?) This all sounds interesting, but I'm certainly
not ready to move all my development to LISP...


- --
Paul R. Potts, Software Designer --- [e-mail] <--- me!

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 22 May 92 20:52:44 GMT
Organization: MacDTS Mongols

In article <[e-mail]>,
[e-mail] (Paul Potts) writes:
> In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
> >Once again, once the rebellion starts, let's select a language paradigm
> >which is 100 times better than the current one, a major step is better
> >than many, many minor ones. OODLs before OOSLs (OOSL - object oriented
> >static language, OODL - object oriented dynamic language).

> I'd love to try one out... right now I'm using C++ on the PC platform
> and THINK C on the Mac. Suppose you are a programmer like me that is
> interested in getting in on the OODL wave early. What languages
> would be appropriate to look at?  I've heard Scheme, Lisp, and
> Smalltalk mentioned. Any others? (And are any of them available as
> shareware or PD?) This all sounds interesting, but I'm certainly
> not ready to move all my development to LISP...

   It is true that we are just in the beginning of the future OODL
language world... Did that sound like something non-evangelistic? "Prepare,
the day is soon here" sounds much better.

   Anyway, I would suggest to just now 'check out' how various Scheme
systems, Macintosh Common Lisp, and SmallTalk looks like, and how
to use them.

   In the case of Scheme, especially Scheme with object extensions, check
out the public domain versions available on altorf.ai.mit.edu.

   MCl costs 495$US, it's a full CLOS implementation, so unless you don't
get the money I'm not sure you could find a PD CLOS implementation that
works directly under MacOS. Many PD systems which works under UNIX are
easy to port over to A/UX, though.

   SmallTalk/V is a nice Smalltalk environment for private exploration.

   This all sounds very much as we are in the beginning of the OODL era,
and that's actually the case. Reminds me of the C++ situation back in 85,
and the case "for a better C". Things should happen quite fast, though,
in future. I personally think the quest is for a common sense Common
LISP, an environment which is not too complex, where a few key words
builds a very complex environment. And where the syntax of LISP will
not cause grief and harm, I mean the common 'too many parenthesis'
syndrome :-). A combination of code generator, CASE tool, visual
programming environment, real code hacking and performance coding
using C as the ultimate tool is maybe something I'm personally envisioning.

And yes, no linker and compiler stages...

- --
                                              Cheers, Kent


+++++++++++++++++++++++++++

From: [e-mail] (Ravinder Chandhok)
Date: Wed, 27 May 92 15:54:11 GMT
Organization: School of Computer Science, Carnegie Mellon

In article 39533 [e-mail] writes:
>...
>And as for parenthesis, that's a syntax issue, and we
>should really look into semantic issues.

Sorry, I think syntax is *extremely* important for writing large systems
that have to maintained over time.  Especially when the semantics allow for
polymorphism, etc.  Do you like the way C++ comes out when you do operator
overloading?

Poo-pooing syntax as the "easy stuff" is not a good long term strategy, IMHO.

Rob
- --
Ravinder (Rob) Chandhok              Internet : [e-mail]
Carnegie Mellon University           AppleLink: A14


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 29 May 92 22:06:21 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Ravinder
Chandhok) writes:
> In article 39533 [e-mail] writes:

> >And as for parenthesis, that's a syntax issue, and we
> >should really look into semantic issues.

> Sorry, I think syntax is *extremely* important for writing large systems
> that have to maintained over time.  Especially when the semantics allow for
> polymorphism, etc.  Do you like the way C++ comes out when you do operator
> overloading?

> Poo-pooing syntax as the "easy stuff" is not a good long term strategy, IMHO.

   Here we disagree, it is true that C++ syntax is a big mess, no orthogonality
whatever. However I've heard so many times statements such as "LISP stinks
because it has too many parenthesis", while those who have used LISP-based
languages for a while suddenly realizes the benefits of compound statements.

   In other words, looking at plain syntax without checking the power behind
(semantics) is the wrong way to judge computer languages *).

   As for C++ operator overloading, "O, what a tangled web we weave,
When first we practice to deceive" - Shakespeare.

- --
                                              Cheers, Kent

*)I think APL fans would agree on this as well.

+++++++++++++++++++++++++++

From: [e-mail] (Ravinder Chandhok)
Date: Mon, 01 Jun 92 12:04:15 GMT
Organization: School of Computer Science, Carnegie Mellon

In article 40153 [e-mail] writes:
>...
>   In other words, looking at plain syntax without checking the power behind
>(semantics) is the wrong way to judge computer languages *).
>...
>*)I think APL fans would agree on this as well.

After realizing that the *) was not some new form of smiley that I didn't
recognize...

My retort, of course, must be that looking at plain semantics without
looking at the syntax is the wrong way to judge a computer language.  You
can have the functionality of lisp without the obtuse syntax.  Ever try to
explain the syntax of a COND statement to a novice?  Ever try to decypher
(from the syntax) which is the nested local "function" inside a another
defun in common lisp?  And, of course, do you actually *like* prefix
notation for your arithmatic expressions?

>   As for C++ operator overloading, "O, what a tangled web we weave,
>When first we practice to deceive" - Shakespeare.

Well said.  Or, well quoted. Shakespeare really knew his programming
languages, eh?

- --
Ravinder (Rob) Chandhok              Internet : [e-mail]
Carnegie Mellon University           AppleLink: A14


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 5 Jun 92 23:58:13 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Ravinder
Chandhok) writes:
> >   In other words, looking at plain syntax without checking the power behind
> >(semantics) is the wrong way to judge computer languages *).
> My retort, of course, must be that looking at plain semantics without
> looking at the syntax is the wrong way to judge a computer language.  You
> can have the functionality of lisp without the obtuse syntax.  Ever try to
> explain the syntax of a COND statement to a novice?  Ever try to decypher
> (from the syntax) which is the nested local "function" inside a another
> defun in common lisp?  And, of course, do you actually *like* prefix
> notation for your arithmatic expressions?

As usually, it takes two to tango. Yes, it's a mixed balance of
syntax and semantics we are really dealing with. However my observation
after years of language flaming is that people look at syntax issues
without reflecting the underlying semantical issues.

"LISP has too many parenthesis". "C code stinks, it looks so cryptic".
"BASIC programs stink, because they need line numbering". And so on.

As for the LISP criticism, yes, these are valid observations. Common
LISP especially went overboard with nifty macros and all kinds of
separate ways to define libraries (good example is the myriad of loop
systems out there today).

Scheme was a form of a mild protest, where the basic building blocks
of the language are very primitive, but build a very nice and complex
environment, to the extreme if needed. And there's no definition
of how libraries should be defined, something which is a hinder
for Scheme to become an industrial standard. C was partly sold
with the help of standard C libraries (and UNIX system call ones) to
the commercial field. This is where Dylan has the class library
well defined, it resembles the Smalltalk collection (everything
is a class) design.

I agree that the binding of variables in LISP languages look weird,
however when we look at the issues of local/global scope LISP has
a far better way of defining the scope than traditional static
languages.

I do like prefix notation, I'm a former HP-junkie, and Polish
notation is the natural way for CPUs to work anyway.

> >   As for C++ operator overloading, "O, what a tangled web we weave,
> >When first we practice to deceive" - Shakespeare.
>
> Well said.  Or, well quoted. Shakespeare really knew his programming
> languages, eh?

Yeah, Shakespeare predicted C++ long time ago. Maybe I should write
a soft cover book about this, to be found in the New Age section in the
book store next year.

- --
                                              Cheerios, Kent


---------------------------

From: [e-mail] (Roby Sherman)
Subject: Drawing on the MeNuBaR!
Date: 26 May 92 15:37:26 GMT
Organization: The Tao of Programming

Hi All.

What is the quickest, cleanest, and easiest way to draw on the menu bar?


                        thanks in advace,

                       Roby
- --
[e-mail]                    Roby Sherman

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 27 May 92 12:48:43 GMT
Organization: The World Public Access UNIX, Brookline, MA

<< What is the quickest, cleanest, and easiest way to draw on the menu bar?
>>

Depending on what you are trying to accomplish, a patch to DrawMenuBar()
will always do the trick and seems to be a popular way of doing things.
- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP.asm   CI$: 70712,515
- -- communications.networks.cool tunes...

+++++++++++++++++++++++++++

From: [e-mail] (Magnetic Technology Center)
Organization: not yet ...
Date: Thu, 28 May 1992 17:13:21 GMT

[???]
[] What is the quickest, cleanest, and easiest way to draw on the menu bar?

[<[e-mail]> [e-mail] (Joe Zobkiw) replies:]
[] Depending on what you are trying to accomplish, a patch to DrawMenuBar()
[] will always do the trick and seems to be a popular way of doing things.

true, however you want to avoid trap patching as a solution, in general!!!
the popularity of trap patching is now passed its peak (with the advent
of multifinder and improved system software, etc.).

the original question is too vague to give a definite answer but ...
at least understand that the menubar is just a specially maintained
region on the screen.  perhaps the solution to your problem lies in
understanding how the window and menu managers conspire to maintain
this region (umm, read Inside Macintosh and Tech Notes :().  with
this approach, who knows?, maybe your hack will be compatible ...

  -dave-  aka no-trap-patch-man!
[e-mail]

"If it ain't broken, don't patch it."

[note: trap patches can be safe and effective if used properly.
  however, frequent usage may be dangerous to the health of your mac.]

[... yes that's an "a", dammit! ...]

+++++++++++++++++++++++++++

From: [e-mail] (Paul Campbell)
Date: 30 May 92 03:04:21 GMT
Organization: Taniwha Systems Design

In article <[e-mail]> [e-mail] (Roby Sherman) writes:
>Hi All.
>
>What is the quickest, cleanest, and easiest way to draw on the menu bar?

Umm ... a felt pen?

    Paul
- --
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P
It's not as well known that 3 days before George Bush puked in the Japanese
Prime Minister's lap our great statesman and diplomat accidently gave the
finger to a whole nation ....

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 4 Jun 92 05:55:47 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Paul Campbell) writes:
> In article <[e-mail]> [e-mail] (Roby Sherman) writes:
>>Hi All.
>>
>>What is the quickest, cleanest, and easiest way to draw on the menu bar?
>
> Umm ... a felt pen?

Hey, he asked for the *cleanest* way!!!

All right, make that a write'n'wipe felt pen...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

From: [e-mail] (William Ross Geck)
Date: 6 Jun 92 00:38:08 GMT
Organization: University of California at Los Angeles, EE Dept.

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>In article <[e-mail]>, [e-mail] (Paul Campbell) writes:
>> In article <[e-mail]> [e-mail] (Roby Sherman) writes:
>>>Hi All.
>>>
>>>What is the quickest, cleanest, and easiest way to draw on the menu bar?
>>
>> Umm ... a felt pen?
>
>Hey, he asked for the *cleanest* way!!!
>
>All right, make that a write'n'wipe felt pen...
>
>Lawrence D'Oliveiro                       fone: [phone]
>Computer Services Dept                     fax: [phone]
>University of Waikato            electric mail: [e-mail]
>Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

Seriously. . .

Quite some time ago, before I discovered the trick with setting the height
of the menu bar to zero, I would add the menu bar to the clip and visable
regions of my window before drawing there.  The reason that you normaly
couldn't draw there is that the menu region is always subtracted from
the window's visible region, and of course all drawing is clipped to that
region.  I have tested the program I did this in since I have begun using
System 7, so I know it still works (or at least while the application is
in the forground).  Also, when receiving mousedown events, if it says it
is in the menu bar, check to see if it is also in your window before
calling menu routines.

I hope this actually answers the original question :)

W. Ross Geck
[e-mail]

---------------------------

From: [e-mail] (David Berger)
Subject: Latest Inside Mac Printings?
Date: 4 Jun 92 14:05:33 GMT
Organization: 3D Software

Could someone inform me of the latest printing versions
of each of the Inside Macintosh Volumes?

Are there any drastic changes with them from older versions?
What new Managers has Apple changed to in the past year or two?

Thanx.

David Berger
3D Software
[e-mail]


- --
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 5 Jun 92 23:48:51 GMT
Organization: MacDTS Mongols

In article <[e-mail]>,
[e-mail] (David Berger) writes:
> Could someone inform me of the latest printing versions
> of each of the Inside Macintosh Volumes?

> Are there any drastic changes with them from older versions?
> What new Managers has Apple changed to in the past year or two?

Well, my humble advice would be to use Inside Mac VI as the prime
book, and switch over to older versions when nothing is explained,
and also look at the TNs just to make sure that this issue is not
also covered by a Tech Note.

Note, there's only one revision of the Inside Macintosh versions, the
only book that has changed is the X-Ref (of course, I'm not that dumb!).

- --
                                              Cheers, Kent


---------------------------

End of C.S.M.P. Digest
**********************